.NEWSS GENERAL SYSTEM OUTLINE
.NEWSSS HARDWARE

	Currently  two  Stanford  Electric  Arms,   built  by  Victor
Scheinman [Scheinman], are available.  They are called YELLOW and BLUE.  Each has
six joints  and a hand  that can  open and  close.   The joints  are
controlled by  electric motors; each joint has both position
and velocity feedback.
Motor  drives are sent from the computer to
the arm via a  digital-to-analog converter (D-to-A); feedback  signals are
routed through an analog-to-digital converter (A-to-D) back to the computer.

	There are two computer-controlled cameras. The 
computer can control the pan, tilt, focus, iris, filter, and zoom
(or lens turret) on each camera.

	Various others devices are designed and implemented as needed.
We use tools, jigs and special markings for several purposes:
to render a task possible (an example is the arm itself), to improve
efficiency (the mechanical screwdriver), and to overcome some of our
sensory and mechanical limitations (the screw dispenser).
Currently we have an electrically powered screwdriver, a pneumatic
vise, and an electrically controlled turntable.  The screwdriver can
be picked up by an arm and operates in either direction over a range
of speeds.  The vise can be opened or closed; soon there will be
a way to servo it to a specified opening.  The computer can position
the turntable to any rotation (within .5 degrees).  As such
devices are built, they will be interfaced to the A-to-D, the servo
told how to control them, and the language extended to include syntax
to describe how to use them.

	'AL  resides on two  computers: The PDP-10  for all planning,
and a PDP-11/45 for the execution of the plans.  The former is run  as a
timesharing computer  (under a  modified DEC  system); the  latter is
operated  in a  stand-alone mode under  the 'AL  runtime system.
 Each
computer is capable of generating an interrupt in the  other, and the
PDP-10 has complete control over the PDP-11 console and unibus.
It is not certain exactly what the minimum runtime computer configuration
will be; we use floating point and memory management, but it is not
clear that this is altogether necessary.


.NEWSSS SOFTWARE

	See {NEWFIG Overall system, FULL, sis←} for a picture of the
system. 

	The SUPERVISOR is the top level of 'AL.  It runs on
the maxi and provides an interface between the user and the other
parts of the system: 1) listening to the user's console and
interpreting input in a simple command language; 2) controling the
compiler, starting it and relaying its error messages back to the
user; 3) signalling the loader when it is necessary to place compiled
code into the mini; 4) handling the runtime interface to the mini. 
Each of these modules is discussed below. 

	The USER sits at a console and makes requests of 'AL.  These
fall into several categories: Compilation, loading, execution of
programs, debugging of code, requesting of status information, asking
for immediate arm motion, saving and restoring the state of the world
at safe points, requesting explanation of certain compiler decisions. 
There are actually two different consoles at which a user can sit:
one is connected to the maxi, through which he can speak to the supervisor
and all the parts of 'AL residing on the maxi; the other is connected
to the mini, and through it the user can investigate the runtime
system and cause modifications.

	The COMPILER reads 'AL programs from files (or, optionally,
directly from the user's console) and produces load modules.  The
compiler is divided into three phases: The PARSER, the EXPANDER, and
the TRAJECTORY CALCULATOR. The compiler is discussed in detail in
{ssref com}. 

	The LOADER takes the load modules prepared by the compiler
and enters them into the mini's runtime system.  Address relocation
and linking are done at this time. The loader also sets up the data
area in the runtime interface in the maxi; this data includes
output strings, procedure linkages, and information necessary for
diagnostic purposes during runtime.  Loading is often done in a
partially incremental fashion, installing new code following
previously loaded code.  

	The RUNTIME INTERFACE, which resides in the
maxi, is charged with initiating the mini
program, fielding procedure calls from the running program to
maxi procedures, returning values from these procedures, and
fetching values from the mini for debugging purposes.  The
interface has the power to interrupt the execution of the program and
to modify the status of the runtime system, for example, by patching
in additional program, or modifying the values of some variables.
This allows the user to control the program through the timesharing
maxi. 

	The RUNTIME SYSTEM is the set of programs which reside in the
mini.  This system includes kernel programs for time-slice cpu
sharing and process control and a set of dynamically created
processes.  These are of three basic types: a) An INTERPRETER
examines the code prepared by the compiler and executes the numeric
computations requested.  When a move is to be started, the
interpreter creates a servo for each joint and waits until all these
servos are finished.  b) A SERVO handles the motion of one moving joint. 
c) A CONDITION-MONITOR repeatedly examines certain conditions
(whatever the programmer has specified).  If it should discover that
its condition has occurred, it creates an interpreter to take
appropriate action.  

	The runtime system has a database which stores the
current values of all active variables and the attachment relations
between them.  Whenever an interpreter needs a value, it is fetched
from this database. 

	Facilities exist for control of the runtime system by
means of the mini's console.  The features that are available include
inspection of the status of all active and dormant processes and the
values of all variables, as well as the insertion of breakpoints and
the ability to insert, delete, or modify code. 

The runtime system also includes routines for communication with the
(maxi's) runtime interface.  The runtime system is described in
detail in {secref run} and Appendix II.